개요

E-쿠버네티스 인증 실습을 하던 차에, 뭔가 계속 kube-apiserver에 로그가 생기는 것을 확인했다.
메트릭 서버와 관련된 이슈로 보였으며, 이 무렵부터 메트릭을 보는 것이 불가능해졌다.
로그를 보니 내가 알 수 없는 ip에 접근을 지속적으로 시도하고 실패하는 것이 보인다.

트러블 슈팅

구조에 대해서는 나중에 따로 정리하겠다.
다만 apiservice 객체가 애초에 잘못된 주소를 가리키고 있는 것이 확인된다.
저 주소는 무엇인가?
대충만 봐도 클러스터 서비스 범위로 지정된 값이다.

이 서비스로의 요청이 계속 실패하고 있는 것인데, 백엔드는 이미 준비 상태이긴 하다.
정확하지는 않으나 해당 컨테이너의 헬스체크 자체는 성공하고 있으니 그냥 트래픽이 완전히 어디론가 경로를 못 찾고 새고 있는 것 같다.
잘 납득은 안 되는 것이, 서비스의 엔드포인트도 정확하게 잡혔고, 타겟 포트도 명확하게 지정돼있는 것을 확인했다.

혹시 몰라 메트릭 서버를 hostNetwork 모드로 다시 실행했더니 이번에는 에러가 이렇게 바뀌었다.

엔드포인트가 정말 잡히지 않고 있는데, 포트 이름은 호스트 네트워크일 때 동작하지 않는 걸까?

는 그냥 해당 포트를 이미 쓰고 있어서 그런 것이었구요..
10250은 kubelet이 보통 노출시키는 포트라 그런 것 같다.
그래서 10251로 포트를 변경했더니 정상적으로 작동하기 시작한다.

왜 이런 문제가 발생했을까?
서비스의 라우팅을 담당하는 것은 kube-proxy이다.
서비스 객체를 확인한 이후 이것에 맞도록 iptables 규칙을 지정해줘야 하는데, 여기에서 문제가 발생한 것이 아닐까 한다.
음.. 혹시 드는 생각인데, 내가 최근에 Calico를 쓰면서 이 놈이 프록시를 대체해버린 건 아닐까?
그리고 이 놈이 제대로 테이블을 만들어주는데 실패한 것이다.
근데 나는 그런 설정을 따로 한 적이 없는데 이게 말이 되나..[^4]

혹시나 해서 내부 트래픽이 제대로 이동되는지 확인해보는데, 이제 보니 Core DNS부터가 제대로 동작하지 않는 것으로 보인다.

직접적으로 서비스 ip를 넣으면 제대로 동작한다.
그렇다며 서비스에 대한 트래픽은 또 제대로 가긴 한다는 것이다.
https://discuss.kubernetes.io/t/micok8s-coredns-connection-timed-out-no-servers-could-be-reached/21706/3

도메인 설정에 문제가 있나 추적해본다.
일단 ip를 통해서 통신을 하려고 하면 잘 되는 것이 확인되었으므로, dns 문제로 가능성을 좁힐 수 있다고 생각한다.

그러나, 노드에서 해당 dns 서버를 이용하는 것은 또 가능하다.

• dns서버로 트래픽이 가기만 하면 정상 동작
• ip로 접근 시 전부 잘만 간다.
  • dns서버만 불가능하다.

dns 설정 파일을 수정해서 로깅이 가능하도록 만들었다.
요청은 제대로 들어왔었다.

..? 갑자기.. 되기 시작한다.
ConfigMap 수정사항을 어플리케이션에서 런타임에 읽어오지 못하는 것 같길래 재기동을 시켜줬는데, 그 이후에 갑자기 되기 시작하는 것 같다.
....
여태 난 무얼 한 것이냐.

결론

사실 이 트러블 슈팅은 이전에 처음 메트릭 서버를 설치할 때 발생했던 일을 다루고 있다.
그러나 이렇게 노트를 분화한 현 시점에는, 더 다양한 트러블슈팅을 하면서 정확한 원인을 알 수 있었다.
구체적으로, 이건 다른 노드 간 서비스 연결이 안 되는 문제였다.
kubeadm을 세팅할 때 초기 스크립트를 양식으로 만들어 전달할 때 잘못 설정한 게 있었던 듯한데, 이후에 그것을 처리하자 문제는 해결됐다.
위에서 문제가 해결됐던 것은, core dns가 테스트를 진행하는 파드와 같은 노드에 있었기 때문이었다.

아무튼 나중에 kubeadm 설정 파일을 더 만지면서 공부를 하려고 한다.

관련 문서

참고